Summary

Following up on #31: <=> now returns nil for non-coercible objects, but the Numeric branch still raised IncompatibleUnitError (a TypeError) whenever two units had incompatible dimensions. Routed through Comparable that surfaced as the unhelpful comparison of Unit with Unit failed, and sort, min, max, between? and clamp blew up with a non-standard error.

Raise ArgumentError directly from <=> when the operands are dimensionally incompatible. Every Comparable path funnels through <=>, so one descriptive message now surfaces consistently from <, >, sort, min, max, between? and clamp.

Operands are labelled following core Ruby's own phrasing, symmetrically in both directions: a dimensional Unit is shown via #inspect, while a bare numeric — or a dimensionless unit, which is just a number and is how a coerced bare numeric arrives — is shown by its class. This avoids splatting an arbitrary #inspect into the message or printing a confusing coerced Unit("1.2").

Unit(1, 'm') <=> Unit(1, 's')     # comparison of Unit("1 m") with Unit("1 s") failed
Unit(1, 'm') > 1.2                # comparison of Unit("1 m") with Float failed
1.2 > Unit(1, 'm')                # comparison of Float with Unit("1 m") failed
[Unit(1, 'm'), Unit(2, 's')].sort # ArgumentError (same message, via <=>)
Unit(100, 'cm') <=> Unit(1, 'm')  # 0  (compatible — unchanged)
[Unit(3,'m'), Unit(1,'m')].sort   # works

Comparing against a genuinely foreign object (nil, a String) still returns nil from <=>, matching 1 <=> "a" — only dimension mismatches between quantities raise. Arithmetic (+/-) deliberately keeps raising IncompatibleUnitError.